Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="pL7XENtVtDG4F41P"


--pL7XENtVtDG4F41P
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

The decision to consider side-channel attacks was already made by the
official NISTPQC evaluation criteria, which state "Schemes that can be
made resistant to side-channel attack at minimal cost are more desirable
than those whose performance is severely hampered by any attempt to
resist side-channel attacks."

There's an ambiguity here that should be officially resolved. Suppose
scheme X costs 100000 without protection and 101000 with protection,
while scheme Y costs 10 without protection and 3000 with protection.
Does X qualify as "minimal cost" because of the small difference between
101000 and 100000, so the evaluation criteria prefer X over Y, unless
someone decides to punish X by speeding up the 100000? (The bizarre
features of a "yes" answer have been pointed out before.) Or does Y
qualify as "minimal cost" because 3000 is the minimum of {3000,101000}?

Either way, it's important to keep in mind here that _evaluating_ the
cost of building side-channel-resistant implementations is challenging:

   * For the relatively simple case of timing attacks, there's a clear
     strategy to verifiably eliminate all data flow from secrets to the
     side channel, but this takes engineering effort that's often
     skipped---and cutting any corner can have disastrous consequences;
     see, e.g., the https://eprint.iacr.org/2021/1485 HQC+BIKE attacks.

   * For the much more complicated case of the attacker being able to
     place (or access) physical sensors close to secrets, it isn't
     plausible that the data flow can be eliminated. Trying to mask
     secrets so that they're expensive to recover from the side-channel
     data is bleeding-edge research, as illustrated by the masked SABER
     implementation broken in https://eprint.iacr.org/2021/079.

Decisions based on claims regarding the cost of side-channel resistance
have to be accompanied by a risk analysis. How likely are the claims to
hold up after further investigation? If the claims turn out to be wrong,
what's the impact on the decision?

Many people also seem to implicitly assume that comparing costs of
_attacks_ against _unprotected_ implementations is a useful predictor of
the costs for _users_ of _protected_ implementations. But the available
evidence is that, no, it's not a useful predictor. For example, we've
previously seen people comparing Classic McEliece to Frodo, so let's try
that comparison on these axes:

   (1) What are the relative costs of Classic McEliece and Frodo in
       various applications? This is already a complicated comparison
       purely from a network-traffic perspective, giving mixed results
       depending on how many ciphertexts are transmitted per public key,
       and then considering CPU time and side-channel protection adds
       further complications.

   (2) What are the relative costs of reported power/EM attacks against
       non-masked implementations of Classic McEliece and Frodo? As far
       as I know, the only direct comparison available is in
       https://eprint.iacr.org/2021/849.pdf, which breaks non-masked
       Frodo in 86016 traces and doesn't succeed in breaking non-masked
       Classic McEliece.

Even if the answer to #2 is stable (I'm skeptical, and certainly
wouldn't recommend making any decisions on that basis), clearly #2 is
not capturing most aspects of #1. #1 is directly addressing NISTPQC
evaluation criteria, whereas the connection of #2 to the evaluation
criteria is tenuous at best.

---D. J. Bernstein

-- 
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20220625075306.872662.qmail%40cr.yp.to.

--pL7XENtVtDG4F41P
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3QolqQXydru4e4ITsMANTjsOVFkFAmK2vuIACgkQsMANTjsO
VFlT9w//daSE1rwLjw7VXcr/JXWzTuSK6M51ZUsKikrqdHxewLnQoRNg0rGAjv3a
EZf0wUXqmlj5k5EesQLThZCF8GvdPxbK4NyUM37zwKCN1mZHYyIO5MrciCdUWFyO
XQ2vVskBtnAX22DpP/O1lxrc1jHhWE97vNrXywrenyb/tZq9rrrvh8TgE+av3gwB
Y9k1S2fN8i2/7huQNcwvR5SukiY9ggmt7nYKJqC4U2m7xpw76FRy0qkva/0CkpkD
V7SXrXip3DTNdgdZ6YjN1PO5KuIdXQCSBMG9hU+HO92JlhcnViIAfZ4uvPj6BqiX
pBkHgkxTMIxFxB+j0ufQJs0ho6OpfYRwR+oZrtBgd3SvGzjr1cRGJyyZB6omsRQX
8PpWOLHSjCydpo8KFB3ZRodNAiOQIn6M0z9z5RnK44TyGrGE3dr4YcsuiMQHCqfJ
IS9X3JWMhIc973gSkJrjosn+PBwRSQs8SxzJyuxcWI516mf46oyh8orSprfBp0nj
PKsnU9tdKvatMSoUeJPeF0wXmWraErnKYgecczpnT3QvqvfKDC7cRLw4dzStNjcw
JG5lf5pFfYXM+C6rrBXLdbLh3AMuLmq7KLln2XbAg4uPlhhemFuc2pnEsK52lotR
E3B2XWEtQooE8b+ybl+TITiUFYWWfi+HM3RNokwJydMiHFGnNkU=
=bvAl
-----END PGP SIGNATURE-----

--pL7XENtVtDG4F41P--